Usage

ticket.custom_field["field name"]            # get
ticket.custom_field["field name"] = "value"  # set; you also need to call ticket.save!

How it works

When #custom_field is called for the first time on any ticket for the client instance, we fetch all ticket_fields and store a mapping from field names to their IDs on that client instance. Following #custom_field will reuse this mapping.

You can call client.refresh_custom_fields_metadata if you expect that definition of fields have changed since the data was loaded.

To enable bracket syntax, custom_field returns a CustomFieldAccessor object with [](field_name) and []=(field_name, value) methods.

The mapping is stored inside account_data hash on a client: I’ve decided to give a more generic name to give future additions an obvious placement. However, we expose a custom fields-specific refresh_custom_fields_metadata method on a Resource so that resources can refresh only that part of account_data which is relevant for them.

Should we preload this metadata?

Initially I added a config key that would enable this preloading and fetch ticket fields during client initialization. We can potentially go back to this, but I think that memory usage is low enough not to warrant an additional configuration flag.

Note on memory usage

A custom fields mapping stored on a client looks like this:

{
  "Subject" => 9000000000001,
  "Description" => 9000000000002,
  "Field one" => 9000000000003,
  "Field two" => 9000000000004
}

(It includes all fields, not only custom ones).

If you have 1000 custom fields with 30-character names, this mapping will need about 40 KB. This shouldn’t matter for most cases, but if you simultaneously have in memory thousands of clients for accounts with thousands of custom fields, memory usage of these mappings might become noticeable.

Alternative implementation: no accessor, worse method names

I’ll squash these commits before merging but for now I wanted to have a commit with a simpler approach (but arguably worse API).

ticket.custom_field_by_name("field name")
ticket.set_custom_field_by_name("field name", "value)

This doesn’t require an additional accessor class. I think ticket.custom_field["field name"] way is much better and worth a bit of complexity.